Vehicles such as cars and trucks, SUVs have an onboard computer and/or controller that is utilized to control and monitor the vehicle's operation. The controller provides for monitoring various operational features and functions related to the vehicle for example communicating with sensors to obtain data, identifying faults, facilitating identifying repair.
The vehicle controller communicates vehicular data available primarily for the vehicle service industry to facilitate detection, identification and repair of vehicle faults. Vehicular data is communicated by the vehicle's central controller and/or processor and/or computer in the form of a message over a Vehicle Data Bus (‘VDB’).
Generally sensors information and the like vehicular operational data is communicated over a standardized communications system between the on-board engine controller and an off-board tool or monitoring device, using various defined protocols including but not limited to ISO-15031; Controller Area Network (CAN); OBD II; J1939 truck standard; ISO 9041 (K-line), or the like vehicular protocol.
Generally the vehicular data is communicated in the form of messages, however, the message format, as example of which may be seen in FIG. 1, and the vehicular data contained within the message is not standardized and greatly varies between manufacturers and vehicle models.
Most messages produced by vehicle's processor, for example as depicted in FIG. 1, generally comprise a header 12, a data payload 14, and checksum and/or End Of File (EOF) indicator 16. The header 12 generally comprises a unique Message ID field (‘MID’), the byte length of the payload. Some messages further comprise a “prefix” field within the payload that is indicative of what data type is contained within the message. However, the prefix is not a standardized indicator where a message may contain a plurality of prefixes, each prefix may be of variable size and location within the message.
The payload itself may comprise data of at least one or more parameters and/or a plurality of different parameters. The parameters communicated within the messages generally take the form of Industry Standard Parameters (‘ISP’) or Manufacturer Specific Parameters (‘MSP’). Generally, ISP parameters are made available by the interrogation process as they are governed by industry standards and legislation. Non-ISP parameters are not governed by legislation and therefore are not necessarily made available by the manufactures, and may be provided in the form of MSP, that are not readily discoverable and/or available.
The vehicular data made available via the communicated messages may be accessed by external systems and/or resources by interrogating the vehicle on board controller for the data in a question and answer process. The question and answer processes requires that the interrogating (asking) device request specific data from the vehicle's controller. Generally the interrogating device is a servicing device utilized for diagnosing the vehicle.
The interrogation and iterative process with the vehicle data bus (VDB) and its associated communication protocols is limited in that it is primarily reserved for facilitating access to vehicular data while the vehicle is not fully operational. For example, while the vehicle being serviced and not while the vehicle is “in full use” and “on-the-road” and/or “on the job”.